does it help at all gas wise to name these return values and use them in the function body?

function encode(int32 x, int32 y) internal pure returns (bytes memory _staticData, PackedCounter, bytes memory) {
  _staticData = encodeStatic(x, y);

tested on Callbacks and Vector2 but it doesn't seem to make a difference. Intuitively I'd also assume that this shouldn't affect bytecode

since we're now passing around this tuple a lot, do you think we'd get any value from encoding this as a struct? or would that make it less convenient, since we don't always use all three values?

struct ValueData {
  bytes staticData;
  PackedCounter encodedLengths;
  bytes dynamicData;
}

edit: nevermind, talked myself out of this idea

it might help in a few tests. Otherwise not sure, it's not used much outside codegen, and codegen is fine either way. Importing a struct isn't very convenient, but neither is a big tuple

I see a lot of folks asking in help channel about stack too deep errors when dealing with lots of variables, is this anything to consider?

yes, it would reduce vars from 3 to 1

might be worth it to support more variables in generated libraries? Since the functions are not used a lot outside codegen I think the slightly decreased dev ex of having to import a struct for the return data is fine

edit: nevermind, talked myself out of this idea

curious why?

I talked myself out of it because there's a bunch of cases where we only carry around e.g. staticData or encodedLengths+dynamicData and it wouldn't make sense to carry them in a "partial" struct. So thought it'd be clearer to carry around just the things you need (explicit vars, even if it means 3 for the case of all data)

the main advantage of using the struct is in the set function, where I believe we'd currently run into "stack too deep" issues for tables where num keys + num fields is greater than 7 (because the set function has 5 additional variables besides the key+fields). That might be worked around if we make the version of setter that uses the table's data struct a "first class citizen" instead of internally calling the version with arguments.

In any case, i think we can do this as a follow up since it involves refactors to code unrelated to this PR. Opened an issue to track here: #1535 and #1536

nit: can we indent this one level (and all the backticks below) for readability?

sure, I went with this style for all renderers so just sticking to it here. If we wanna change it I'd rather make a separate PR and change it everywhere

we already did this: #1474
just wanna keep it consistent with the new format

oh right I missed that one, yeah all the other files are good and I was just focused on record, will fix